home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
PsL Monthly 1993 December
/
PSL Monthly Shareware CD-ROM (December 1993).iso
/
prgmming
/
dos
/
c
/
tagsgen.exe
/
WILDFILE.DOC
< prev
next >
Wrap
Text File
|
1992-01-06
|
15KB
|
387 lines
WildFile for MS-DOS systems
A *IX SH style file globber written in C
V1.20 Dedicated to the Public Domain
January 07, 1992
J. Kercheval
[72450,3702] -- johnk@wrq.com
01-07-92
This is V1.20 of Wildfile.
Thanks to F. C. Smith for a bug fix when expanding paths of the form
c:* rather than the fully qualified c:\*. This version also utilizes
the generic match code from MATCH V1.20 with appropriate ifdef's for
use with the MSDOS path follow character.
jbk
05-13-91
This is V1.14 of Wildfile.
Thanks to David Kirschbaum of Toad Hall for adding support for Turbo C
V2.0.
jbk
05-07-91
This is V1.13 of Wildfile, a *IX SH style file Globber.
The purpose of this code is to enable the programmer to allow *real*
wildcard file specification. The UNIX (*IX) SH style wildcard system
has been around for decades and there is absolutely no good reason for
it's lack of presence within MS/PC DOS and its associated tools.
I submit this without copyright and with the clear understanding that
this code may be used by anyone, for any reason, with any modifications
and without any guarantees, warrantee or statements of usability of any
sort.
jbk
*IX SH style wildcard file globbing
===================================
The unix style of wildcard globbing (matching files to a wildcard
specification) is quite a bit more flexible than the standard
approach seen on the MS\PC DOS machines. The full power of *IX SH
style regular expressions are allowed to specify a file name. For
instance:
"*t*" would match to the filenames test.doc, wet.goo,
itsy.bib, foo.tic, etc.
"th?[a-eg]." would match to any file without an extension,
whose first two letters were "th", with any third
letter and whose last letter was a,b,c,d,e or g.
(ie. thug, thod, thud, etc.)
"*" would match all filenames.
The regular expression syntax is described in detail in the source
code and below.
Implementation
==============
The implementation of the wildcard package is similar in type to the
standard MS/PC DOS function calls for file searches. There is a
find_firstfile call which begins a search initially and a
find_nextfile call which continues a previous search. This approach
will normally yield a very quick port from existing *standard*
implementations of wildcard file searching.
The include file WILDFILE.H does a good job of describing the
specifics required here.
WD
==
WD is a very quick implementation of a directory lister to try to
show the usage of the wildfile module as intended. The program is a
fully functional program complete with usage messages and command
line argument parsing.
Languages
=========
WILDFILE (and its associated module MATCH) were developed and
compiled using both MicroSoft C V6.00A and Borland C++.
============================================================================
============================================================================
MATCH120
REGEX Globber (Wild Card Matching)
A *IX SH style pattern matcher written in C
V1.20 Dedicated to the Public Domain
January 07, 1992
J. Kercheval
[72450,3702] -- johnk@wrq.com
01-07-91
This is V1.2 of REGEX Globber.
To clarify code I have added defines for the standard characters used
within a match pattern and have reformatted the source code. There
is an internal define to allow this code to be used in filename
regular expression globbing for the MSDOS platform. This consisted
of disabling the use of the literal escape outside of a range so that
path follows (ie '\') would be handled correctly.
jbk
03-12-91
This is V1.1 of REGEX Globber.
03-12-91
I have made a few changes to the match module which do several
things. The first change is an increase in bad pattern detection
during a match. It was possible, in some very unlikely cases, to
cook up a pattern which should result in an early bad match but which
would actually cause problems for the parser. In particular, the
subcase where the literal escape '\' within an open [..] construct at
the end of a pattern would end up with incorrect results. I
proceeded to create some of these patterns, added them to my test
battery and dove straight in.
In the interim I came across a posting to CompuServe (SMATCH by Stan
Aderman) which attempted to create a completely non-recursive
implementation of match (I am not sure this is possible without
explicitly creating your own stack or it's equivalent, like a binary
tree :-{ ). While the code could not correctly handle multiple '*'
characters in the pattern, there was a few interesting ideas in the
posting. On some occasions, running match over and over would be
counter productive, especially and in particular when you have a bad
pattern. I have added a fast routine, is_valid_pattern(), to
determine if the current pattern is well formed which should address
this situation.
One other idea which I unceremoniously lifted from SMATCH was (in
hindsight a pretty obvious feature) the return of a meaningful error
code from both the pattern validity routine and from match() (which I
renamed to matche()).
I also took some time to experiment with some ways to cut some time
off the routine. Since this is a SH pattern matcher whose intent is
primarily for shell functions, the changes could not be algorithmic
changes which relied on speedup over large input. The differences in
execution time were not very significant, but I did manage to gain
approximately 5%-10% speedup when I removed the literal escape ('\')
parsing and pattern error checking. For those of you who want to use
this for filename wildcard usage, I would recommend doing this since
you should use is_valid_pattern and is_pattern before going out and
finding filenames and the dos path delimiter defaults to the
character used for the literal escape ('\') anyway (Note: I will be
soon be releasing a *IX style file parser in the FINDFILE, FINDNEXT
flavor soon to a Public Domain archive near you :-) ).
I also briefly toyed with adding a non-SH regex character '+' to this
module but removed it again. It was a performance hit of a few
percent and would be mostly unused in any event. For those
interested in such a feature, the changes are truly minimal. The
required extra work is:
1) One case statement each in is_pattern() and is_valid_pattern()
2) One case statement in matche()
3) One addition to a while conditional in matche_after_star()
4) One addition to an if conditional in matche_after_star()
Hint: The case statements are all "case '+'" and the conditionals
have "|| *p == '+' " added to them.
I have also included a file (MATCH.DOC) which describes matches use and
background as well as a little about regular expressions.
jbk
02-24-91
This is V1.01 of REGEX Globber.
02-22-91 Seattle, WA
Hmm. Choke. (Foot in mouth). After griping about buggy routines and
literally seconds after posting this code the first time, I received
a wonderful new test evaluation tool which allows you to perform
coverage analysis during testing. Sure enough I found that about
25% of the paths in the program were never traversed in my current
test battery. After swallowing my (overly large) pride and coming
up with a test battery which covered the entire path of the program
I found a couple of minor logic bugs involving literal escapes (\)
within other patterns (ie [..] and * sequences). I have repackaged
these routines and incl